Properly use createOneInstanceComponentFactory for javaloader
After 424a7f404565e068995e2a9827d5bc6f76920ec8 "add some more libs to libmerged"
had added javaloader to libmerged, destruction of static xStaticRef started to
cause problems at least during CppunitTest_services of --enable-mergedlib
Windows builds (presumably because the relative order of static variable
destruction had changed).
Change-Id: I8307570222cc9a3d9511d090d0dae7f7dfe7a9ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90254
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
diff --git a/stoc/source/javaloader/javaloader.cxx b/stoc/source/javaloader/javaloader.cxx
index 065ff12..d6f77cd 100644
--- a/stoc/source/javaloader/javaloader.cxx
+++ b/stoc/source/javaloader/javaloader.cxx
@@ -336,21 +336,13 @@
/// @throws Exception
static css::uno::Reference<XInterface> JavaComponentLoader_CreateInstance(const css::uno::Reference<XComponentContext> & xCtx)
{
css::uno::Reference<XInterface> xRet;
try {
MutexGuard guard( getInitMutex() );
// The javaloader is never destroyed and there can be only one!
// Note that the first context wins...
static css::uno::Reference< XInterface > xStaticRef = *new JavaComponentLoader(xCtx);
xRet = xStaticRef;
return *new JavaComponentLoader(xCtx);
}
catch(const RuntimeException &) {
TOOLS_INFO_EXCEPTION("stoc", "could not init javaloader");
throw;
}
return xRet;
}
} //end namespace
@@ -362,7 +354,7 @@
{
{
JavaComponentLoader_CreateInstance, loader_getImplementationName,
loader_getSupportedServiceNames, createSingleComponentFactory,
loader_getSupportedServiceNames, createOneInstanceComponentFactory,
nullptr , 0
},
{ nullptr, nullptr, nullptr, nullptr, nullptr, 0 }